Methods for implementation of an eject service for a removable disk drive

ABSTRACT

Embodiments provide systems and methods for ejecting a removable disk drive. To prevent data corruption from the eject operation, a shell extension can be stored in the server requesting the eject. The shell extension can monitor and intercept eject commands from the operating system of the server and send the commands to an eject service. The eject service, in embodiments, checks the status of the removable disk drive and ejects the removable disk drive only when the removable disk drive is not busy with another operation.

BACKGROUND

Embodiments of the disclosure generally relate to storage systems and,more specifically, but not by way of limitation, to archiving storagesystems.

Governments and other organizations often require the storage of certaintypes of data for long periods. For example, the Securities and ExchangeCommission (SEC) may require retention of financial records for three ormore months. Thus, entities that have to meet these storage requirementsemploy archiving systems to store the data to a media allowing forlong-term storage. The systems, in some situations, employ removabledisk drives.

Further, the archiving systems may employ a file system toelectronically organize and store the material to the removable diskdrives. In some situations, the file system allows for the disk drive tobe ejected. However, in some situations, the file system allows the diskto be ejected while the disk is performing a function to the data on thedisk. These occurrences generally result in corrupted data on the disk.Corrupted data is avoided in these archiving systems because the datamay be required in future retrievals.

It is in view of these and other considerations not mentioned hereinthat the embodiments of the present disclosure were envisioned.

BRIEF SUMMARY

Embodiments of the present disclosure provide unique and novel systemsand methods for ejecting removable disk drives. The removable diskdrives described are controlled by an operating system that allows ejectoperations. However, a separate eject service monitors such operationsand intervenes if the disk is in operation. The eject service waits fora period of time to allow the disk to finish the operation. After theoperation is finished, the eject service allows the eject. As such, datacorruption is avoided and the disk eject command occurs. Alternativesystems and methods are also presented.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments of the present disclosure are described in conjunctionwith the appended figures:

FIG. 1 is a block diagram of an embodiment of a removable cartridgestorage system;

FIG. 2 is a hardware block diagram of an embodiment of an archivingsystem including one or more removable cartridge storage systems;

FIG. 3 is a functional block diagram of an embodiment of an archivingsystem;

FIG. 4 is a hardware block diagram of an embodiment of a modular drivebay having two or more removable disk drives;

FIG. 5 is a functional block diagram of an embodiment of a modular drivebay;

FIGS. 6A and B are block diagrams of embodiments of software modules foran eject service to complete ejects of removable disk drives;

FIGS. 7A and 7B are flow diagrams of an embodiment of a method forejecting a removable disk drive;

FIG. 8 is flow diagram of another embodiment of a method for ejecting aremovable disk drive; and

FIG. 9 is a flow diagram of an embodiment of a method for ejecting aremovable disk drive.

In the appended figures, similar components and/or features may have thesame reference label. Further, various components of the same type maybe distinguished by following the reference label by a dash and a secondlabel that distinguishes among the similar components. If only the firstreference label is used in the specification, the description isapplicable to any one of the similar components having the same firstreference label irrespective of the second reference label.

DETAILED DESCRIPTION

The ensuing description provides exemplary embodiment(s) only and is notintended to limit the scope, applicability or configuration of thepossible embodiments. Rather, the ensuing description of the exemplaryembodiment(s) will provide those skilled in the art with an enablingdescription for implementing one or more embodiments. It beingunderstood that various changes may be made in the function andarrangement of elements without departing from the spirit and scope ofthe possible embodiments as set forth in the appended claims.

Embodiments disclosed herein provide an eject service in communicationwith a file system. The file system may be, for example, Microsoft's® NTFile System. Other file systems are possible. The file system allowsejects of a removable disk drive from a disk drive bay. The eject, inembodiments, is requested from a user interface interaction or from theengagement of a mechanical device, for example, an eject button. Thefile system, in response to the eject request, may attempt to eject theremovable disk drive. In embodiments, the eject service monitors thefile system and determines the file system is attempting an eject. Theeject service can intervene to intercept commands or requests going toor coming from the file system. Embodiments of the eject servicedetermine a condition of the removable disk drive, for example, is theremovable disk drive writing data to the drive. If an operation isoccurring that, if interrupted, will result in data corruption, theeject service can delay the eject command. After the operation iscomplete, the eject service can allow the eject. In the followingdescription, exemplary embodiments of the archiving system withremovable disk drives are described.

An embodiment of a removable disk system 100 to provide long-termarchival data storage is shown in FIG. 1. The removable disk system 100and description related to the removable disk system is being providedas one or many possible removable disk systems that could use an ejectservice. In embodiments, the eject service is executed in a server thatis in communication with the removable disk system, as explained inconjunction with FIGS. 6A through 9. A removable disk drive 102 providesstorage capability for the removable disk system 100. In embodiments,the removable disk drive 102 includes a data cartridge case 108 and anembedded memory 104, which may be one of, but is not limited to, anembedded hard disk drive (HDD), solid state disk (SSD), solid statedrive, or flash memory. The HDD or flash memory 104 provides RAM for thestorage of archived data. The embedded memory 104 is in communicationwith and/or electrically connected to a connector 106. In oneembodiment, the connector is a Serial Advanced Technology Attachment(SATA) connector. In other embodiments, the connector is a UniversalSerial Bus (USB) connector, parallel connector, Firewire connector, orother connector. Both the embedded memory 104 and connector 106 are, inembodiments, physically attached to the data cartridge case 108, and, insome embodiments, enclosed, protected, connected or integrated by thedata cartridge case 108. In other embodiments, the embedded memory 104and the connector 106 are a physically integrated component and theconnector 106 protrudes from the data cartridge case 108. The datacartridge case 108, in embodiments, provides a solid container for theembedded memory 104 that also functions as an easily swappable orchanged case when interchanging removable disk drives 102 in theremovable disk system 100.

The embedded memory 104, in embodiments, includes metadata 118. Metadata118, in embodiments, allows the archiving system to provide differentfunctionality with the removable disk drive 102. Metadata 118 caninclude any information about the data stored in the memory 104. Theinformation can include memory addresses, protection formats for thedata, encryption keys, etc. With the metadata 118 stored in the embeddedmemory 104, the removable disk drive 102 may be physically stored apartfrom the removable disk drive system 102 and allow the removable diskdrive 102 to be later reinserted with the same functionality.

In embodiments, the removable disk system 100 contains a drive port 110that includes one or more data cartridge ports 112, each with a datacartridge connector 114 to receive the removable disk drive 102. Thedata cartridge connector 114 mates with the electrical connector 106 ofthe removable disk drive 102 to provide an electrical connection to theremovable disk drive 102 and/or to communicate with the embedded memory104 in the removable disk drive 102. As with the electrical connector106, the data cartridge connector 114 may be a SATA connector or anothertype of connector. Regardless, the data cartridge connector 114 and theelectrical connector 106 can be physically and/or electricallyconnected. The data cartridge port 112 allows the data cartridge case108 of the removable disk drive 102 to be easily inserted and removed asnecessary. In embodiments, the drive port 110 includes two or more datacartridge ports 112 to allow for the use, control and communication withtwo or more removable disk drives 102. Each drive port 110, inembodiments, is separately addressable to allow for customized controlover each removable disk drive 102 connected to each data cartridge port112. Thus, as removable disk drives 102 are replaced, the same controlscan be applied to the newly inserted removable disk drives 102 becausethe drive port 110 is addressed instead of the removable disk drives102. In embodiments, the removable disk drives 102 can be ejected fromthe drive port 110 upon issuance of an ejection command. The ejectioncommand may be issued by a software system or be issued in response tothe mechanical engagement of a physical ejection button or interface.

The embedded memory 104 may be read and used by the hardware/firmware116 of the drive port 110. The hardware/firmware 116 may be hardwareand/or software resident in the drive port 110 for controlling theremovable disk drive 102. In embodiments, the hardware/firmware 116contains the necessary software and/or hardware to power-up theremovable disk drive 102, spin-up the disk platters in the embeddedmemory 104, read and write to the embedded memory 104, read, write andprocess metadata 118, etc. For example, the hardware/firmware 116 couldread the embedded memory 104 to identify the removable disk drive 102and gather information related to the drive's contents.

In embodiments, the removable disk system 100 operates to receive one ormore removable disk drives 102 in the one or more drive ports 110. Theelectrical connector 106 physically connects or couples with the datacartridge connector 114 to form an electrical connection that allows thedrive port 110 to communicate with the embedded memory 104. Thehardware/firmware 116 powers-up the embedded memory 104 and begins anyinitialization processes (e.g., security processes, identificationprocesses, reading and/or writing, etc.). The drive port 110, which, inembodiments, is in communication with a network, receives archival datafrom one or more servers, applications, or other devices or systems onthe network. The hardware/firmware 116 writes the archival data to theembedded memory 104 of the removable disk drive 102 to archive the data.

An embodiment of the hardware architecture of an archiving system 200 isshown in FIG. 2. The archiving system 200, in embodiments, comprises anetwork storage system 202 in communication with one or more systems viaa network 204. In embodiments, the systems that communicate with thenetwork storage system 202 comprise applications, application servers,other servers, peripherals, other devices, and other systems thatarchive data on the network storage system 202. For example, applicationserver 1 206 and/or application server 2 208 store archival data on thenetwork storage system 202. The application servers 206 and/or 208 canexecute the eject service. An application server 206 or 208 may be anapplication, peripheral device, system, network component, or othersoftware function or hardware device that may store archived data.Hereinafter, all functions, systems, processes, hardware devices thatmay store archived data will be referred to as an application orapplication server. Application server 1 206 and application server 2208 will hereinafter be used to describe the functions of the archivingsystem 200 but are not meant to limit the description to the exemplaryembodiments set forth herein.

The network storage system 202 comprises one or more components that maybe encompassed in a single physical structure or be comprised ofdiscrete components. In embodiments, the network storage system 202includes an archiving system appliance 210 and one or more removabledisk drives 224, which may be the same or similar to removable diskdrive 102 (FIG. 1), connected or in communication with a drive port 222,which may be the same or similar to drive port 110 (FIG. 1). Inalternative embodiments, a modular drive bay 212 and/or 214 includes twoor more drive ports 222 that can each connect with a removable diskdrive 224. Thus, the modular drive bays 212 and 214 provide addedstorage capacity because more than one removable disk drive 224 can beinserted and accessed using the same archiving system appliance 210.Further, each drive port 222 in the modular drive bays 212 and 214 are,in embodiments, separately addressable allowing the archiving systemappliance 210 to configure the removable disk drives 224 in the modulardrive bays 212 and 214 into groups of one or more removable disk drives224. Two or more modular drive bays 212 and 214, in embodiments, areincluded in the network storage system 202, as evidenced by the ellipses218. Thus, as more data storage capacity is required, more modular drivebays 212 and 214 may be added to the network storage system 202. Inembodiments, each modular drive bay 212 and 214 may include a singlehardware/firmware 116 (FIG. 1) for all drive ports 222 in the modulardrive bays 212 and 214. In alternative embodiments, each drive port 222includes hardware/firmware 116 (FIG. 1).

The exemplary hardware architecture in FIG. 2 provides near limitlesscapacity as more removable disk drives 224 can be added to existingmodular drive bays 212 or 214 until the modular drive bays 212 and 214hold all possible removable disk drives 224. Then, more modular drivebays 212 and 214 are added to the network storage system 202. Further,removable disk drives 224 may be replaced as the removable disk drives224 near their storage capacity. The removed disk drives 224, inembodiments, are physically stored if and until the data on theremovable disk drives 224 needs to be retrieved. If the data on theremovable disk drive 224 needs to be retrieved, the removable disk drive224 may be inserted into one of the drive ports 222 of the modular drivebay 212 or 214, and the information retrieved from the connectedremovable disk drive 224.

The archiving system appliance 210, in embodiments, is a serveroperating as a file system. The archiving system appliance 210 may beany type of computing system having a processor and memory and operableto complete the functions described herein. An example of a server thatmay be used in the embodiments described herein is the PowerEdge™ 2950Server offered by Dell Incorporated of Austin, Tex. The file systemexecuting on the server may be any type of file system, such as the NTFile System (NTFS), that can complete the functions described herein.Hereinafter, the archiving system appliance 210 may be referred to asthe host.

In embodiments, the two or more modular drive bays 212 and/or 214,having each one or more inserted removable disk drives 224, form aremovable disk array (RDA) 232. The archiving system appliance 210 canconfigure the RDA 232 into one or more independent file systems. Eachapplication server 206 or 208 requiring archiving of data may beprovided a view of the RDA 232 as one or more independent file systems.In embodiments, the archiving system appliance 210 logically partitionsthe RDA 232 into application layer partitions and logically associatesone or more drive ports 222 with each application layer partition. Anapplication layer partition is associated with the application server206 or 208 rather than some arbitrary logical divisions. Thus, the oneor more removable disk drives 224 comprising the application layerpartition appears as an independent file system.

In further embodiments, the archiving system appliance 210 provides aninterface for application server 1 206 and application server 2 208 thatallows the application servers 206 and 208 to communicate archival datato the archiving system appliance 210. The archiving system appliance210, in embodiments, determines where and how to store the data to oneor more removable disk drives 224. For example, the application server 1206 stores archival data in a first application layer drive, such as,the first three removable disk drives. The application layer drives are,in embodiments, presented to the application servers 206 and 208 asapplication layer drives where write and read permissions for any oneapplication layer drive is specific to one of the application servers.As such, the network storage system 202 provides a multiple andindependent file system to each application server 206 and 208 using thesame hardware architecture. In embodiments, the archival data is alsoreferred to as an information element and may include, but is notlimited to, a file, a memory sector, a data structure, a table, or othertype or format of data.

In alternative embodiments, the network storage system 202 alsocomprises a fixed storage 216. The fixed storage 216 may be any type ofmemory or storage media either internal to the archiving systemappliance 210 or configured as a discrete system. For example, the fixedstorage 216 is a Redundant Array of Independent Disks (RAID), such asthe Xtorc XJ-SA12-316R-B from AIC of Taiwan. The fixed storage 216provides an active archive for storing certain data for a short periodof time where the data may be more easily accessed. In embodiments, thearchiving system appliance 210 copies archival data to both the fixedstorage 216 and the removable disk drive 224. If the data is needed inthe short term, the archiving system appliance 210 retrieves the datafrom the fixed storage 216. The archiving system appliance 210, inembodiments, sends the archival data to or removes the archival datafrom the modular drive bay 212 or 214 having a predetermined address tostore or retrieve the archival data from a removable disk drive 224.

The archiving system appliance 210 can also configure the active archivein the fixed storage 216 into one or more independent file systems, aswith the RDA 232. As explained above, each application server may beprovided a view of one of two or more independent file systems. Eachindependent file system may comprise an application layer partition inthe RDA 232 and a related application layer partition in the fixedstorage 216. In embodiments, the archiving system appliance 210partitions the fixed storage 216 and associates each application layerpartition in the fixed storage 216 with an associated application layerpartition in the RDA 232.

As explained above, the archiving system appliance 210, in embodiments,determines where and how to store the data to one or more removable diskdrives 224. For example, the application server 1 206 stores archivaldata in a first application layer drive, which may include storing thearchival data in the application layer partition in the fixed storage216 for easier access to the archival data. Again, the application layerdrives are, in embodiments, presented to the application servers 206 and208 where write and read permissions for any one application layer driveis specific to one of the application servers. As such, the networkstorage system 202 provides a multiple and independent file system toeach application server 206 and 208 using the same hardwarearchitecture.

In operation, application server 1 206 stores primary data into aprimary storage 228, which may be a local disk drive or other memory.After some predetermined event, the application server 1 206 reads theprimary data from the primary storage 228, packages the data in a formatfor transport over the network 204 and sends the archival data to thenetwork storage system 202 to be archived. The archiving systemappliance 210 receives the archival data and determines where thearchival data should be stored. The archival data, in embodiments, isthen sent to the related application layer partitions in both the fixedstorage 216 and the RDA 232, which may comprise one or more of theremovable disk drives 224 in one or more of the drive ports 222. Thearchiving system appliance 210 can retrieve or receive a memoryaddress(es) for the data to be stored in the removable disk drive 224.The archival data is written to the removable disk drive 224 forlong-term storage and is written to the fixed storage 216 forshort-term, easy-access storage. In further embodiments, applicationserver 2 208 writes primary data to a primary storage 230 and also sendsarchival data to the network storage system 202. In some embodiments,the archival data from application server 2 208 is stored to a differentremovable disk drive 224 and a different portion of the fixed storage216 because the archival data from application server 2 208 relates to adifferent application and, thus, a different application layerpartition.

A block diagram of an archiving system 300 is shown in FIG. 3. Thearchiving system 300 has one or more functional components that, inembodiments, includes a network storage system 302 in communication witha network 304. The network 304 may be any type of communicationinfrastructure, for example, one or more of, but not limited to, awide-area network (WAN), local area network (LAN), wireless LAN, theInternet, etc. The network storage system 302 may communicate with oneor more other systems coupled to, connected to, or in communication withthe network 304. For example, the network storage system 302communicates with an application server 306. Communications betweensystems on the network 304 may occur by any protocol or format, forexample, Transmission Control Protocol/Internet Protocol (TCP/IP), HyperText Transfer Protocol (HTTP), etc.

The network storage system 302, in embodiments, comprises one or morefunctional components embodied in hardware and/or software. In oneembodiment, the network storage system 302 comprises an archiving system312 in communication with one or more drive ports 322 that are incommunication with one or more removable disk drives 324. The driveports 322 and removable disk drives 324 are the same or similar infunction to those described in conjunction with FIGS. 1 and 2. Thearchiving system 312 controls the function of the one or more driveports 322 and writes the archived data to one or more predeterminedremovable disk drives 324 in the one or more drive ports 322.

In further embodiments, the network storage system 302 comprises anarchival management system 310. The archival management system 310receives data for archiving from one or more systems on the network 304.Further, the archival management system 310 determines to which systemor removable disk drive 324 the data should be archived, in which formatthe data should be saved, and how to provide security for the networkstorage system 302. In embodiments, the archival management system 310provides a partitioned archive such that the network storage system 302appears to be an independent file system to each separate applicationserver 306, yet maintains the archive for multiple application servers306. Thus, the archival management system 310 manages the networkstorage system 302 as multiple, independent file systems for one or moreapplication servers 306. In embodiments, the archival management system310 and the archiving system 312 are functional components of thearchiving system appliance 210 (FIG. 2).

In embodiments, the archival management system 310 saves archival datato both the archiving system 312 and an active archive 314. The activearchive 314, in embodiments, controls, reads from and writes to one ormore fixed storage devices 316 that allow easier access to archiveddata. In embodiments, fixed storage 316 is similar in function to fixedstorage 216 (FIG. 2). The active archive 314 performs similar functionsto the archiving system 312 but for the fixed storage devices 316. Inembodiments, the active archive 314 and the fixed storage devices 316are components of the hardware fixed storage system 216 (FIG. 2). Inalternative embodiments, the active archive 314 partitions the fixedstorage 316 to mirror the associated application layer partitions in theRDA 320. The application layer partition(s) in the active archive 314may have boundaries associated with memory addresses in the fixedstorage 316.

The archival management system 310 may also provide an intelligentstorage capability. Each type of data sent to the network storage system302 may have different requirements and controls. For example, certainorganizations, such as the SEC, Food and Drug Administration (FDA),European Union, etc., have different requirements for how certain datais archived. The SEC may require financial information to be kept forseven (7) years while the FDA may require clinical trial data to be keptfor thirty (30) years. Data storage requirements may includeimmutability (the requirement that data not be overwritten), encryption,a predetermined data format, retention period (how long the data willremain archived), etc. The archival management system 310 can applycontrols to different portions of the RDA 320 and the active archive 314according to user-established data storage requirements. In oneembodiment, the archival management system 310 creates application layerpartitions in the archive that span one or more removable disk drives324 and one or more portions of the fixed storage 316. All data to bestored in any one application layer partition can have the samerequirements and controls. Thus, requirements for data storage areapplied to different drive ports 222 (FIG. 2) in the modular drive bays212 and 214 (FIG. 2) and to the removable disk drives 224 (FIG. 2)stored in those drive ports 222 (FIG. 2). Further, the requirements arelikewise applied to different portions of the fixed storage 316 in theactive archive 314. If a removable disk drive 324 is replaced, the samestorage requirements, in embodiments, are applied to the replacementremovable disk drive 324 because of its location in the controlled driveport 322. As such, the archival management system 310 can individuallymaintain separate sets of data using different controls, even indifferent removable disk drives 324. Still further, the importance ofmaintaining the data requires that the data not be corrupted or deletedaccidentally. As such, special controls are applied to actions, such asthe ejection of the removable disk drives 324, that protect theintegrity of the data.

The network storage system 302 may also comprise a database 318 incommunication with the archival management system 310. The database 318is, in embodiments, a memory for storing information related to the databeing archived. The database 318 may include HDDs, ROM, RAM or othermemory either internal to the network storage system 302 and/or thearchival management system 310 or separate from the network storagesystem 302 and/or the archival management system 310, as a discretecomponent addressable by the archival management system 310. Theinformation stored in the database 318, in embodiments, includes one ormore of, but is not limited to, data identification, application serveridentification, time of storage, removable disk drive identification,data format, encryption keys, application layer partition organization,etc.

The network 304, in embodiments, connects, couples, or otherwise allowscommunications between one or more other systems and the network storagesystem 302. For example, the application server 306 is connected to thenetwork storage system 302 via the network 304. The application server306 may be a software application, for example, an email softwareprogram, a hardware device, or other network component or system. Theapplication server 306, in embodiments, communicates with a memory thatfunctions as the application server's primary storage 308. The primarystorage 308 is, in embodiments, an HDD, RAM, ROM, or other memory eitherlocal to the application server 306 or in a separate location that isaddressable.

In embodiments, the application server 306 stores information to theprimary storage 308. After some predetermined event, such as theexpiration of some period of time, the application server 306 sends datato the network storage system 302 to archive the data. The applicationserver 306 may send the data by any network protocol, such as TCP/IP,HTTP, etc., over the network 304 to the network storage system 302. Thedata is received at the archival management system 310. The archivalmanagement system 310, in embodiments, sends the data to one or both ofthe active archive 314 and/or the archiving system 312 to be archived.

Embodiments of the hardware/firmware 400 of the modular drive bay isshown in FIG. 4. In embodiments, the hardware/firmware 400 is the sameor similar to hardware/firmware 116 explained in conjunction withFIG. 1. The hardware/firmware 400, in embodiments, comprises a firstinterface (interface #1) 406, a processor 402, a memory 404, and asecond interface (interface #2) 408. In embodiments, the first interface406 receives archival data from the host 410 for storage in a removabledisk drive 412 and/or sends archived data from the removable disk drive412 to the host 410. Removable disk drive 412 is, in embodiments, thesame or similar to removable disk drive 102 described in conjunctionwith FIG. 1. The first interface 406 can be any type of interfaceoperable to communicate with the host 410. In embodiments, the host 410is the archiving system appliance 210 (FIG. 2) and/or archiving system312 (FIG. 3). The first interface 406 can be a Firewire, USB, SATA, orother interface.

The processor 402 is operable to execute software or firmware stored inmemory 404 for storing or retrieving archival data from the removabledisk drive 412. The processor 402, in embodiments, is any processorknown in the art for executing the functions described herein. Forexample, the processor 402 is an Intel Pentium, ASIC, FPGA, or otherdevice. The processor 402 interfaces with the first interface 406 toreceive archival data for storage and to send data requested from thehost 410. The processor 402 further interfaces with the second interface408 to send data to the removable disk drive 412 and to read data fromthe removable disk drive 412. The memory 404 may be any type of memoryincluding RAM, ROM, disk drive, etc. The memory 404 may store data ormetadata and interfaces with the processor 402.

In embodiments, the second interface 408 retrieves archival data fromthe removable disk drive 412 to send to the host 410 and sends archivaldata to the removable disk drive 412 for storage. The second interface408 can be any type of interface operable to communicate with theremovable disk drive 412. The second interface 408 can be a Firewire,USB, SATA, small computer system interface (SCSI), or other interface.

A functional block diagram of an embodiment of the hardware/firmware 500of the modular drive bay is shown in FIG. 5. In embodiments, thehardware/firmware 500 is the same or similar to hardware/firmware 116explained in conjunction with FIG. 1 or hardware/firmware 400 describedin conjunction with FIG. 4. In embodiments, the hardware/firmware 500represents software executed in the hardware/firmware 400 (FIG. 4). Thehardware/firmware 500, in embodiments, comprises an interface selectionmodule 508, an access control module 502, a metadata datastore 504, acommand pass-through module 506, and/or a disk drive interface 510.

In embodiments, the interface selection module 508 receives requestsfrom the host 512 to store or retrieve archival data. The host 512 maysend the requests with a predetermined address for the archival data.The interface selection module 508 can extract the address received fromthe host 512 to which to store or retrieve the archival data. Thisaddress is, in embodiments, provided to the access control module 502.

The access control module 502 is operable to read metadata from themetadata datastore 504. The access control module 502, in embodiments,builds the metadata datastore 504 by reading the metadata from the oneor more removable disk drives 514 and storing the metadata in a table orother data structure in the metadata datastore 504. In embodiments, themetadata datastore 504 provides a first available block address to storedata in a removable disk drive 514. The first available block addresscan be used by the access control module 502 to determine where to beginto store data. The access control module 502 can be executed within theprocessor 402 (FIG. 4).

In embodiments, the command pass-through module 506 sends the commandsto the removable disk drive 514. For example, if the request from thehost 512 is for a read of data, the command pass-through module 506executes a read on the removable disk drive 514. The requested commandsent from the host 512 may be in one format or comply with one filesystem. The command pass-through module 506 may change the command to acommand understandable by the removable disk drive 514. In furtherembodiments, the access control module 502 provides the commandpass-through module 506 with the first available block address to ensurethe command pass-through module 506 stores data at the correct addressin the removable disk drive 514.

The disk drive interface 510, in embodiments, is a disk drive driver orother software that allows the command pass-through module 506 tointerface with the removable disk drive 514. Thus, the disk driveinterface 510 may convert commands for the removable disk drive 514. Inalternative embodiments, the disk drive interface 510 also receivesinputs from the removable disk drive 514. For example, if a mechanicaleject button is depressed, the removable disk drive 514 or the driveport 110 (FIG. 1) holding the removable disk drive 514 sends the ejectsignal to the disk drive interface 510. The disk drive interface 510 maythen send the eject signal to the access control module 502.

Two embodiments of software systems 600 and 602 for ejecting a removabledisk drive 608 are shown in FIGS. 6A and 6B, respectively. The softwaresystems 600 and/or 602 can execute in a server or computing system incommunication with a removable disk drive system. The eject service 606may be a component of the application server 206 (FIG. 2). In otherembodiments, the eject service 606 may execute in the archivalmanagement system 310 (FIG. 3) and/or the archiving system 312 (FIG. 3).The eject service is the one or more software and or hardware componentsoperable to eject a removable disk drive 608 and/or send, receive, oroperate on eject commands, whether hardware signals and/or softwarecalls. In embodiments, an eject service 606 includes operations toexecute an eject command 610 or directive.

The eject service 606, in one embodiment, may execute in a shellextension 604, as shown in FIG. 6A. In an alternative embodiment, theshell extension 604 executes as a separate component in communicationwith the eject service 606, as shown in FIG. 6B. The shell extension 604may be software and/or hardware operable to monitor the commands fromthe operating system and/or user interface of the server 206 (FIG. 2)and react to those commands in one or more predetermined ways. Forexample, the shell extension 604 intercepts eject commands 610 from theoperating system and sends the commands to the eject service 606 toprevent data corruption or execute the eject. In embodiments, the shellextension 604 executes in the server 206 (FIG. 2), and, in otherembodiments, the shell extension 604 executes in the archival managementsystem 310 (FIG. 3), the archiving system 312 (FIG. 3), the processor402 (FIG. 4), the access control module 502 (FIG. 5), and/or the commandpass through module 506 (FIG. 5).

The eject command 610 may be issued in one or several ways. In oneembodiment, a user chooses to eject a removable disk drive 608 using auser interface. The eject command 610 may be received from a userinterface device, such as a mouse or keyboard, interacting with a userinterface device, such as an window icon. In other embodiments, theeject command 610 is a hardware signal from a mechanical device, such asan eject button. The hardware signal may be passed to the operatingsystem and onto the eject service 606 by one or more components, such asthe disk drive interface 510 (FIG. 5).

In operation, the eject service 606 receives the eject command 610. Theshell extension 604 monitors the commands being issued to the removabledisk drive 608. For example, the shell extension 604 reads the commandsin the software stack of the operating system before being issued. Inresponse to the issuance of the eject command 610 by the operatingsystem, the shell extension 604 intercepts the eject command 610 andpasses the command to the eject service 606. The eject command 610 mayhave been from a user interface or a hardware device. The eject service606 determines the removable disk drive 608 to eject and sends a signalto a drive, for example, the drive port 110 (FIG. 1), to eject theremovable disk drive 608. Then, the eject service 606 determines if theremovable disk drive 608 is busy, for example, completing an operation,which if interrupted, could cause data corruption or other problems. Ifthere is no operation being completed or if the operation can beinterrupted, the eject service 606 forwards the eject command 610 to thedrive to eject the removable disk drive 608. However, if the removabledisk drive 608 is executing an operation, which if interrupted, wouldcause data corruption or other problems, the eject service 606 holds thecommand for a predetermined period of time. After the operation iscomplete, the eject service 606 can send the eject command 610 to thedrive to eject the removable disk drive 608.

In alternative embodiments, the eject service 606 recognizes theinsertion of a removable disk drive 608 into a drive port 110 (FIG. 1).During the initialization of the removable disk drive 608, the ejectservice 606 issues a lock command to the eject service 606 or the driveport 110 (FIG. 1). The lock command prevents the ejection of the device.The lock command is important for file systems that allow a user toeject the removable disk drive 608 using a mechanical button regardlessof what operation the removable disk drive 608 is currently performing.As such, the eject service 606 can prevent data corruption even foroperating systems that allow certain types of mechanical ejectoperations.

An embodiment of a method 700 for ejecting a removable disk drive isshown in FIGS. 7A & 7B. In embodiments, the method 700 generally beginswith a START operation 702 and terminates with an END operation 728. Thesteps shown in the method 700 may be executed in a computer system as aset of computer executable instructions. While a logical order is shownin FIG. 7, the steps shown or described can, in some circumstances, beexecuted in a different order than presented herein. The method 700, inembodiments, relates to the eject service 606 described in conjunctionwith FIGS. 6A & 6B. The method 700, in embodiments, relates to an ejectoperation 610 (FIG. 6) completed in response to the activation of amechanical eject button on a drive port 110 (FIG. 1).

Open operation 704 opens the device. In embodiments, the eject service606 (FIG. 6) opens the device to communicate with device. For example,the eject service 606 (FIG. 6) uses the PhysicalDrive access to open thedrive. Using PhysicalDrive prevents an operating system operation. suchas a Microsoft® Windows® operation, from sending write directives to thedrive and slowing operations being completed by the drive. Further,using PhysicalDrive also allows the eject service 606 (FIG. 6) tocommunicate with the drive even if Windows or the operating systemcannot communicate with the drive.

Determine operation 706 determines if the drive opened is a removabledisk drive 102 (FIG. 1). In embodiments, the eject service 606 (FIG. 6)determines if the opened device is a removable disk drive 102 (FIG. 1).The eject service 606 (FIG. 6) may access data stored about theremovable disk drive 102 (FIG. 1) in the database 318 (FIG. 3) or indata stored resident with the eject service 606 (FIG. 6). In otherembodiments, the eject service 606 (FIG. 6) communicates with the deviceand receives information that identifies the device as a removable diskdrive 102 (FIG. 1). If the device is a removable disk drive 102 (FIG.1), the method flows YES to determine operation 708. If the device isnot a removable disk drive 102 (FIG. 1), the method flows NO to waitoperation 716. In alternative embodiments, another operation may also becompleted before or after the wait operation 716 if the device is not aremovable disk drive 102 (FIG. 1).

Determine operation 708 determines if a removable disk drive 102(FIG. 1) is inserted. In embodiments, the eject service 606 (FIG. 6)determines if an identified removable disk drive 102 (FIG. 1) isinserted into the drive. In embodiments, the eject service 606 (FIG. 6)communicates with the removable disk drive 102 (FIG. 1) and receivesinformation that indicates that the removable disk drive 102 (FIG. 1) isinserted in the drive. If the removable disk drive 102 (FIG. 1) isinserted, the method flows YES to retrieve operation 710. If theremovable disk drive 102 (FIG. 1) is not inserted, the method flows NOto wait operation 716. In embodiments, the eject service 606 (FIG. 6)uses the IOCT_STORAGE_GET_MEDIATYPES_EX command to determine if theremovable disk drive 102 (FIG. 1) is inserted. Unlike the TEST UNITREADY command, the IOCT_STORAGE_GET_MEDIATYPES_EX does not stealUNIT_ATTENTION from the removable disk drive 102 (FIG. 1) if theremovable disk drive 102 (FIG. 1) was recently inserted.

Retrieve operation 710 retrieves the information about the removabledisk drive 102 (FIG. 1). In embodiments, the information includes thevendor identifier (ID) and/or product information. The eject service 606(FIG. 6), in embodiments, retrieves the vendor identifier and/or productinformation, for example, the type of removable disk drive 102 (FIG. 1),capacity, date created, etc. The retrieved information may be retrievedfrom a database, for example, the database 318 (FIG. 3), or in datastored resident with the eject service 606 (FIG. 6). Alternatively, theeject service 606 (FIG. 6) may access metadata stored on the removabledisk drive 102 (FIG. 1). In embodiments, the eject service 606 (FIG. 6)retrieves the vendor ID and the product information using the IOCTLcommand to the device driver.

Determine operation 712 determines if the device is supported. Inembodiments, the eject service 606 (FIG. 6) uses the vendor identifierand/or the product information to determine if the removable disk drive102 (FIG. 1) is supported by the eject service 606 (FIG. 6). Forexample, the eject service 606 (FIG. 6) determines if the drivers existfor the removable disk drive 102 (FIG. 1). If the removable disk drive102 (FIG. 1) is supported, the method flows YES through connector A 714to update operation 720 shown in FIG. 7B. If the removable disk drive102 (FIG. 1) is not supported, the method flows NO through connector B718 to wait operation 716.

Wait operation 716 waits a predetermined period of time. The period oftime may be a second, minute, hour, or other unit of time. Inembodiments, the wait operation 716 allows the eject service 606 (FIG.6) to sleep for some time before retrying the operation. For example,the removable disk drive 102 (FIG. 1) may not have been inserted andthen is inserted, and the operation can then be completed after waitingthe predetermined period of time. Thus, cycling through the waitoperation 716 creates a loop that retries operations when not allowedfor one reason or another.

Update operation 720 updates the clock and transfer mode. Inembodiments, the eject service 606 (FIG. 6) updates data used by theeject service 606 (FIG. 6). Thus, the eject service 606 (FIG. 6) storesthe current status of the clock for the removable disk drive 102(FIG. 1) and the transfer mode condition of the removable disk drive 102(FIG. 1). The data may be stored in a temporary memory structure. Thetransfer mode, in embodiments, is the ultra direct memory access (UDMA)mode. The clock may be the removable disk drive's 102 (FIG. 1) real timeclock.

Determine operation 722 determines if the eject button is selected. Theeject service 606 (FIG. 6) can determine if the eject button wasactivated. The eject button is, in embodiments, a mechanical devicephysically pushed by a user. In embodiments, the eject service 606 (FIG.6) uses the small computer system interface (SCSI) GET_EVENT_STATUScommand to determine if the eject button was selected. If the ejectbutton was selected, the method flows YES to determine operation 724. Ifthe eject button was not selected, the method flows NO through connectorB 718 to wait operation 716 shown in FIG. 7A.

Determine operation 724 determines if the device is busy. Inembodiments, the eject service 606 (FIG. 6) uses the UDMA transfer modeupdated in update operation 720 to determine the status of the removabledisk drive 102 (FIG. 1). In other embodiments, the eject service 606(FIG. 6) requests the current status from the removable disk drive 102(FIG. 1). If the removable disk drive 102 (FIG. 1) is not busy, themethod flows YES to eject operation 710. If the removable disk drive 102(FIG. 1) is busy, the method flows NO through connector B 718 to waitoperation 716 shown in FIG. 7A.

Eject operation 726 ejects the device. The eject service 606 (FIG. 6)can send an eject command 610 (FIG. 6) to the drive to eject theremovable disk drive 102 (FIG. 1). The drive can then eject theremovable disk drive 102 (FIG. 1) in response to the command. Anembodiment of an eject operation 726 is described in conjunction withFIG. 9.

An embodiment of a method 800 for ejecting a removable disk drive isshown in FIG. 8. In embodiments, the method 800 generally begins with aSTART operation 802 and terminates with an END operation 812. The stepsshown in the method 800 may be executed in a computer system as a set ofcomputer executable instructions. While a logical order is shown in FIG.8, the steps shown or described can, in some circumstances, be executedin a different order than presented herein. The method 800, inembodiments, relates to the eject service 606 described in conjunctionwith FIGS. 6A & 6B. The method 800, in embodiments, relates to an ejectoperation completed in response to the selection, in a user interface, aeject user interface device, for example, a menu item, an icon, etc.

Receive operation 804 receives an eject signal from a user interface. Inembodiment, the user selects a user interface device, for example, amenu item, an icon, etc., to eject the removable disk drive 102 (FIG.1). The shell extension 604 (FIG. 6) can intercept the selection signaland instantiate the eject service 606 (FIG. 6). The eject service 606(FIG. 6) may then function to complete the eject. The eject service 606(FIG. 6) allows a user to eject the removable disk drive 102 (FIG. 1)with operating systems that may not be operable to eject the removabledisk drive 102 (FIG. 1).

Determine operation 806 determines if the device is busy. Inembodiments, the eject service 606 (FIG. 6) requests the current statusfrom the removable disk drive 102 (FIG. 1). In other embodiments, theeject service 606 (FIG. 6) attempts to send an eject command to theremovable disk drive 102 (FIG. 1) and may receive an error because theremovable disk drive 102 (FIG. 1) is busy. If the removable disk drive102 (FIG. 1) is not busy, the method flows YES to eject operation 810.If the removable disk drive 102 (FIG. 1) is busy, the method flows NOthrough connector B 718 to wait operation 716 shown in FIG. 7A.

Wait operation 808 waits a predetermined period of time. The period oftime may be a second, minute, hour, or other unit of time. Inembodiments, the wait operation 808 allows the eject service 606 (FIG.6) to sleep for some time before retrying the operation. For example,the removable disk drive 102 (FIG. 1) may be busy completing a writeoperation, and the eject can be completed after waiting thepredetermined period of time. Thus, cycling through the wait operation808 creates a loop that retries operations when not allowed for onereason or another. In embodiments, after the wait operation 808, theeject service 606 (FIG. 6) waits for another eject signal from theoperating system. In alternative embodiments, the eject service 606(FIG. 6) alerts the operating system of the failed eject. The operatingsystem can alert the user, through a display on the user interface, thatthe eject signal or eject selection failed. The user may then retry theeject.

Eject operation 726 (FIG. 7B) ejects the device. The eject service 606(FIG. 6) can send an eject command to the drive to eject the removabledisk drive 102 (FIG. 1). The drive can then eject the removable diskdrive 102 (FIG. 1) in response to the command. An embodiment of an ejectoperation 726 (FIG. 7B) is described in conjunction with FIG. 9.

An embodiment of a method 900 for ejecting a removable disk drive isshown in FIG. 9. In embodiments, the method 900 generally begins with aSTART operation 902 and terminates with an END operation 918. The stepsshown in the method 900 may be executed in a computer system as a set ofcomputer executable instructions. While a logical order is shown in FIG.9, the steps shown or described can, in some circumstances, be executedin a different order than presented herein. The method 900, inembodiments, relates to the eject service 606 described in conjunctionwith FIGS. 6A & 6B. The method 900, in embodiments, relates to an ejectoperation 726 (FIG. 7B) and/or 810 (FIG. 8).

Wait operation 904 waits a predetermined period of time. The period oftime may be a second, minute, hour, or other unit of time. Inembodiments, the wait operation 904 allows the operating system todetect the insertion of the removable disk drive 102 (FIG. 1), if theremovable disk drive 102 (FIG. 1) was just inserted into the drive. Forexample, the removable disk drive 102 (FIG. 1) may not have beeninserted and then is inserted, and the removable disk drive 102 (FIG. 1)is detected after waiting the predetermined period of time.

Retrieve operation 906 retrieves the serial number. The eject service606 (FIG. 6), in embodiments, retrieves the serial number. The retrievedserial number may be retrieved from the database 318 (FIG. 3) or in datastored resident with the eject service 606 (FIG. 6). Alternatively, theeject service 606 (FIG. 6) may access metadata stored on the removabledisk drive 102 (FIG. 1). In embodiments, the eject service 606 (FIG. 6)retrieves the serial number based on the PhysicalDrive operation.

Determine operation 908 determines the drive letter. In embodiments, theeject service 606 (FIG. 6) determines the drive letter from the serialnumber or other information. The drive letter may be associated with theserial number or other data in the database or in data stored residentwith the eject service 606 (FIG. 6). Alternatively, the eject service606 (FIG. 6) may access metadata stored on the removable disk drive 102(FIG. 1) and lookup the drive letter using the serial number.

In embodiments, the eject service 606 (FIG. 6) sends an atomic command,represented by the box 916, that completes the lock operation 910, thedismount operation 912, and the eject operation 914. The lock operation910 locks the removable disk drive 102 (FIG. 1). The dismount operation912 dismounts the removable disk drive 102 (FIG. 1). Finally, theejection operation 914 physically ejects the removable disk drive 102(FIG. 1) from the drive port 110 (FIG. 1).

Specific details were given in the preceding description to provide athorough understanding of the embodiments. However, it will beunderstood by one of ordinary skill in the art that the embodiments maybe practiced without these specific details. For example, circuits maybe shown in block diagrams in order not to obscure the embodiments inunnecessary detail. In other instances, well-known circuits, processes,algorithms, structures, and techniques may be shown without unnecessarydetail in order to avoid obscuring the embodiments. A computing systemmay be used to execute any of the tasks or operations described herein.In embodiments, a computing system includes memory and a processor andis operable to execute computer-executable instructions stored on acomputer readable medium that define processes or operations describedherein.

Also, it is noted that the embodiments can also be described as aprocess which is depicted as a flowchart, a flow diagram, a data flowdiagram, a structure diagram, or a block diagram. Although a flowchartmay describe the operations as a sequential process, many of theoperations can be performed in parallel or concurrently. In addition,the order of the operations may be re-arranged. A process is terminatedwhen its operations are completed but could have additional steps notincluded in the figure. A process may correspond to a method, afunction, a procedure, a subroutine, a subprogram, etc. When a processcorresponds to a function, its termination corresponds to a return ofthe function to the calling function or the main function.

Moreover, as disclosed herein, the term “storage medium” may representone or more devices for storing data, including read only memory (ROM),random access memory (RAM), magnetic RAM, core memory, magnetic diskstorage mediums, optical storage mediums, flash memory devices and/orother machine-readable mediums for storing information. The term“machine-readable medium” includes, but is not limited to, portable orfixed storage devices, optical storage devices, wireless channels andvarious other mediums capable of storing, containing or carryinginstruction(s) and/or data.

Furthermore, embodiments may be implemented by hardware, software,firmware, middleware, microcode, hardware description languages, or anycombination thereof. When implemented in software, firmware, middlewareor microcode, the program code or code segments to perform the necessarytasks may be stored in a machine-readable medium such as a storagemedium. A processor(s) may perform the necessary tasks. A code segmentmay represent a procedure, a function, a subprogram, a program, aroutine, a subroutine, a module, an object, a software package, a class,or any combination of instructions, data structures, or programstatements. A code segment may be coupled to another code segment or ahardware circuit by passing and/or receiving information, data,arguments, parameters, or memory contents. Information, arguments,parameters, data, etc. may be passed, forwarded, or transmitted via anysuitable means including memory sharing, message passing, token passing,network transmission, etc.

In light of the above description, a number of advantages of the presentdisclosure are readily apparent. For example, the eject service andshell extension can eject a removable disk drive even if a server usesan operating system that may not be capable of the eject. Further, ifthe removable disk drive is busy performing an operation, the ejectservice waits for the operation to complete before ejecting theremovable disk drive. Thus, the eject service prevents an ejectoccurring when the eject could create corrupt or lost data.

A number of variations and modifications of the disclosure can also beused. For example, the user may be given a message about the ejectrequest and how, if completed, the eject will cause data loss. The usermay be able to select to continue regardless of the problems that theeject may cause.

It will be apparent to those skilled in the art that substantialvariations may be made in accordance with specific requirements. Forexample, customized hardware might also be used, and/or particularelements might be implemented in hardware, software (including portablesoftware, such as applets, etc.), or both. Further, connection to othercomputing devices such as network input/output devices may be employed.

While the principles of the disclosure have been described above inconnection with specific apparatuses and methods, it is to be clearlyunderstood that this description is made only by way of example and notas limitation on the scope of the disclosure.

1. A method, executable in a computer system, for protecting theintegrity of data when a manual eject button is activated for a device,the method comprising: determining if the device is a removable diskdrive; determining if the removable disk drive is busy; if the removabledisk drive is busy, waiting a period of time; and if the removable diskdrive is not busy, ejecting the removable disk drive.
 2. The method asdefined in claim 1, wherein determining if the device includes accessinginformation on the removable disk drive.
 3. The method as defined inclaim 1, further comprising determining if an eject button was pushed.4. The method as defined in claim 1, wherein ejecting the removable diskdrive comprises sending a sequence of commands.
 5. The method as definedin claim 4, wherein the sequence of commands comprises: locking theremovable disk drive; dismounting the removable disk drive; andphysically ejecting the removable disk drive.
 6. The method as definedin claim 1, further comprising intercepting an eject command at an ejectservice.
 7. The method as defined in claim 6, wherein the eject serviceintercepts the eject command issued by an operating system in responseto an eject signal from an eject button.
 8. The method as defined inclaim 1, further comprising ejecting the removable disk drive after theperiod of time.
 9. A server system operable to eject a removable diskdrive from an archiving system, the server system comprising: aprocessor operable to execute one or more instructions; a memory incommunication with the processor, the memory storing the one or moreinstructions executed by the processor, the instructions operable toexecute one or more software components, the software componentscomprising: an operating system, the operating system operable toreceive a first eject signal from a user interface associated with aremovable disk drive, the operating system operable to receive a secondeject signal from an eject button associated with the removable diskdrive; a shell extension, the shell extension in communication with theoperating system, the shell extension operable to intercept the firsteject signal or the second eject signal; and an eject service incommunication with the shell extension, the eject service operable toreceive the first intercepted eject signal or the second interceptedeject signal, the eject service operable to determine if the removabledisk drive can be ejected, if the removable disk drive can be ejected,the eject service operable to eject the removable disk drive.
 10. Theserver system as defined in claim 9, wherein in response to the secondintercepted eject signal, the eject service opens the device, determinesif the device is a removable disk drive, if the device is a removabledisk drive, retrieves the information about the removable disk drive,determines if the removable disk drive is supported, if the removabledisk drive is supported, determines if a eject button was selected, ifthe eject button was selected, determines if the removable disk drive isbusy, and if the removable disk drive is not busy, ejects the removabledisk drive.
 11. The server system as defined in claim 9, wherein inresponse to the first intercepted eject signal, determines if theremovable disk drive is busy, and if the removable disk drive is notbusy, ejects the removable disk drive.
 12. The server system as definedin claim 9, wherein the eject comprises: locking the removable diskdrive; dismounting the removable disk drive; and sending a command tophysically eject the removable disk drive.
 13. The server system asdefined in claim 9, wherein the operating system cannot eject theremovable disk drive without the eject service.
 14. The server system asdefined in claim 9, wherein the eject service waits a predeterminedperiod of time if the removable disk drive cannot eject and attempts toeject again the removable disk drive after the predetermined period oftime.
 15. A server system operable to eject a removable disk drive froman archiving system, the server system comprising: a processor operableto execute one or more instructions; a memory in communication with theprocessor, the memory storing the one or more instructions executed bythe processor, the instructions comprising: instruction for receiving aneject signal from an operating system to eject a removable disk drive;instructions for determining if the removable disk drive is busy; if thedevice is not busy, instructions for ejecting the removable disk drive;if the device is busy, instructions for waiting a predetermined periodof time; and instructions for receiving a next eject signal from theoperating system.
 16. The server system as defined in claim 15, whereina shell extension intercepts the eject signal from the operating systemand forwards the eject signal to an eject service to eject the removabledisk drive.
 17. The server system as defined in claim 16, wherein theoperating system cannot eject the removable disk drive without the ejectservice.
 18. The server system as defined in claim 15, wherein theinstructions for ejecting the removable disk drive comprise instructionsfor sending a sequence of commands to eject the removable disk drive.19. The server system as defined in claim 18, wherein the sequence ofcommands comprises: instructions for locking the removable disk drive;instructions for dismounting the removable disk drive; and instructionsfor physically ejecting the removable disk drive from the drive port.20. The server system as defined in claim 17, further comprisinginstructions to alert the user that the eject signal was unsuccessful.